-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Deriving: Include bound generic params in type parameters for where clause #89341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deriving: Include bound generic params in type parameters for where clause #89341
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
r? @jackh726 |
I think this looks correct. I was trying to come up with an example without GATs where we could run into this case, but I haven't been able to yet. We basically have to name a late-bound lifetime within the type but without also being required to name it outside. (So, I think I'd like to see the following added to the test: trait CallWithShim2: Sized {
type Shim<T>;
}
struct S<'s>(&'s ());
#[derive(Clone)]
struct ShimMethod2<T: CallWithShim2 + 'static>(
pub &'static dyn for<'s> Fn(&'s mut T::Shim<S<'s>>),
);
trait Trait<'s, 't> {}
#[derive(Clone)]
struct ShimMethod3<T: CallWithShim2 + 'static>(
pub &'static dyn for<'s> Fn(&'s mut T::Shim<dyn for<'t> Trait<'s, 't>>),
);
trait Trait2 {
type As;
}
#[derive(Clone)]
struct ShimMethod4<T: Trait2 + 'static>(
pub &'static dyn for<'s> Fn(&'s mut T::As),
); |
) { | ||
let stack_len = self.bound_generic_params_stack.len(); | ||
self.bound_generic_params_stack | ||
.extend(trait_ref.bound_generic_params.clone().into_iter()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would probably break by HRTB variable shadowing, e.g.
for<'a> (... for<'a> ( ... ))
by outputting for<'a, 'a>
? Unsure if it's important enough to address?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was trying to come up with a test case where this might happen. But I'm unsure; I couldn't find one.
Okay, can you instead actually change the test case to: trait Trait<'s, 't, 'u> {}
#[derive(Clone)]
struct ShimMethod3<T: CallWithShim2 + 'static>(
pub &'static dyn for<'s> Fn(&'s mut T::Shim<dyn for<'t> Fn(&'s mut T::Shim<dyn for<'u> Trait<'s, 't, 'u>>)>),
); This better tests multiple levels of binding. Made me remember that we don't allow lifetime shadowing, so we should be good. |
After that change, this PR LGTM to merge. |
@bors r+ rollup=never Given that this effects built-in derives, I want to make sure this is easy to bisect if there are any regressions. |
📌 Commit 87241e9 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (f03eb6b): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Fixes #89188.
The
derive
macro ignored thefor<'s>
needed with theFn
trait in that code example.edit: I'm unsure if this might cause regressions. I'm not an experienced compiler developer so I'm not used to thinking about unwanted side effects code changes like this might have.